Skip to content

Conversation

@mirenradia
Copy link
Contributor

Summary

This allows the user to create a vector of MultiFabs (one per level) with the derived quantity computed on each level. The overloads match those in AmrLevel.

Additional background

Checklist

The proposed changes:

  • fix a bug or incorrect behavior in AMReX
  • add new capabilities to AMReX
  • changes answers in the test suite to more than roundoff level
  • are likely to significantly affect the results of downstream AMReX users
  • include documentation in the code and/or rst files, if appropriate

//! each Multifab in mf
void derive (const std::string& name,
Real time,
Vector<std::unique_ptr<MultiFab>>& mf,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we should change this to Vector<MultiFab*> const& mf. There are two main advantages. (1) The user might have Vector<MultiFab> mf. It's hard for them to use the unique_ptr interface. (2) The ownership is unclear in the unique_ptr interface. The function takes Vector<std::unique_ptr<MultiFab>> & mf. Is the function going to resize the vector? is the function going to allocate new MultiFabs? The raw pointer interface give the user a clear signal, because the vector is const that prevents the modification of the raw pointers. It's up to the user to own the MultiFabs in the vector.

Note that amrex provides a helper function for converting from Vector<std::unique_ptr<T>> to Vector<T*>. https://amrex-codes.github.io/amrex/doxygen/namespaceamrex.html#a75a0cde85de080ac29b7c4510da71e16 So if you have Vector<std::unique_ptr<MultiFab>> mf, you can just call derive(..., amrex::GetVecOfPtrs(mf));.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That makes sense. I've made the change to this overload. Are you happy with leaving the other overload returning Vector<std::unique_ptr<MultiFab>>? I guess the reasons you give don't really apply in this case.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, returning Vector<std::unique_ptr> is fine.

This allows the user to create a vector of MultiFabs (one per level)
with the derived quantity computed on each level. The overloads match
those in AmrLevel.
@WeiqunZhang
Copy link
Member

I merged development branch into this so that the CUDA ci can pass.

@WeiqunZhang WeiqunZhang enabled auto-merge (squash) November 14, 2025 19:59
@WeiqunZhang WeiqunZhang merged commit 4159c72 into AMReX-Codes:development Nov 14, 2025
73 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants